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(57) ABSTRACT 

A number of protocols are disclosed for providing simplified 
security for a series of low-cost transactions carried out 
between a client and a server within an on-going client- 
server relationship. A key establishment protocol is used to 
generate a shared key which will be used by the client and 
server for the series of transactions. The client generates the 
shared key as a function of a client identifier, a server 
identifier and secret client information, encrypts the shared 
key using a public key of the server, and sends the encrypted 
shared key to the server. The server responds by incorpo- 
rating server information into a response which is encrypted 
using the shared key and sent to the client. The client 
decrypts the response, verifies that the server has accepted 
the shared key, and then sends additional client information, 
such as a credit card number, to the server, using the shared 
key for encryption. The client may then use the shared key 
in a series of subsequent transactions with the server. The 
subsequent transactions may be in accordance with a data 
delivery protocol in which the client requests information, 
and the server supplies the information encrypted using the 
shared key. The server may require that the client demon- 
strate possession of the shared key before responding to a 
data delivery request. The generation and use of the shared 
key may be made substantially transparent to the client 
through the use of a client-side web proxy. 

26 Claims, 3 Drawing Sheets 
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SIMPLIFIED SECURE SHARED KEY low-cost transactions carried out between a client and a , 

ESTABLISHMENT AND DATA DELIVERY server within an on-going client -server relationship. In one j 

PROTOCOLS FOR ELECTRONIC embodiment of the invention, a novel simplified key estab- 

COMMERCE lishment protocol (SKEP) is used to establish a shared key | 

5 which may be used for the scries of transactions. The client I 
FIELD OF THE INVENTION generates the shar ed key by comp uting, for example, th e I 

„_ . . II * i . ■ . *• Janus function of (i) anient identifier, (ii) a server identifier ! 

The invention relates generally to electronic transactions — Tr " ~ r'" " *• , TTTkTTu — TT~ \ 

over computer network!, and more particularly to tech- andOjOjs^ encrffite thejhaiedtey ' 

niques for ensuring security of electronic transactions with- usrn^a public key of the server, and sendsi^encrx^eaM 

out the need for key exchange or other complex arrange- 10 sharcdtejMoJtaj^ server responds by incorpo- 

ments for each transaction. ™ an & server information into a response which is encrypted 

using the shared key and sent to the client. The client 
BACKGROUND OF THE INVENTION decrypts the response, verifies that the server has accepted 

Transaction security has become an increasingly impor- the shared key, and then encrypts and sends additional client 

tant aspect of communication over the Internet and other 15 information such as a credit card number to the server using 
types of wide area computer networks. A number of security encryption based on the shared key. The server may in turn 
techniques developed recently operate at the transport/ respond with an encrypted signature which may be used to 
session layer of a computer network operating in accordance provide a non -repudiation feature, such that the server 
with the Transmission Control Protocol/Internet Protocol cannot later deny having entered into the series of transac- 

(TCP/IP) standard. These techniques include the Secure 20 tions with the client. 

HyperText Transport protocol (S-HTTP), described in E. The client can use the shared key generated in accordance 
Rescorla and A. Schiffrnan, "The Secure HyperText Trans- with the SKEP protocol in all of its subsequent transactions 
port Protocol," Internet Draft, draft-ietf-wts-shttp-OO.txt, with the server, by simply recomputing the shared key via 
July 1995, the Secure Shell (SSH) protocol, described in T. the Janus function. This eliminates the need for a separate 

Ylonen, "SSH— Secure Login Connections Over the 25 k ey exchange for each transaction, and also eliminates the 
Internet," USENIX Workshop on Security, 1996, and the need to store shared keys between different transactions. The 
Secure Socket Layer (SSL) protocol, described in P. Karlton, invention thereby considerably reduces the complexity and 
A. Freier and P. Kocher, "The SSL Protocol," 3.0, Internet cost associated with providing secure client-server commu- 
Draft, March 1996. These and other security mechanisms nications over the Internet and in numerous other applica- 

implemented at the transport/session layer generally have 30 tions. Moreover, because the client need not rely on data 
the advantage of providing universal security "primitives" stored in secure memory, the security techniques of the 
which have a wide applicability. For example, the SSL and invention are well-suited for use in mobile computing appli- 
SSH protocols can be used in conjunction with any TCP cations. 

connection in the network. However, this universality comes ^ SUDSequent client-server transactions may be con- 

at the expense of a lack of flexibility in the complexity and 35 ducted m accordance with a s i mp iifi e d or extended data 
cost of transactions, and a lack of user mobility. More delivery prot ocol (SDDP or ED DP) based on the above- 
particularly, transactions which are within the same client- described shared key. In the SDDP protocol, the client 
server relationship but execute at different times will gen- requests information, and the server supplies the information 
erally appear to the network transport layer as unrelated encryple d using the shared key. The client sends certain 

transactions, or may require the storage of data in secure 40 additiona n nforma tion, such as a random nonce, with its data 
long-term memory at the client side. delivery request, such that the client can readily verify that 

Emerging applications in electronic commerce often t he response is associated with that request. The EDDP 
involve very low-cost transactions, which execute in the pro tocol operates in a similar manner, but requires that the 
context of an ongoing, extended client-server relationship, c ^ ent demonstrate possession of the shared key to the server 

The increase in low-cost electronic transactions and the need 45 before the server responds to a data delivery request, and 
for "low-cost crypto" is described in, for example, R.Rivest, a is 0 prevents third parties from determining the type of 
"Perspectives on Financial Cryptography," Invited Lecture, information requested by the client. 
Proc. of Financial Cryptography '97 Springer-Verlag. For ^ ation and ^ of a shared k m accor dance with 
these low-cost transactions, the above-noted general- ^ invention be made substantially transparent to the 

purpose security mechanisms tend tc^prohibitively expen- 50 ^ h ^ ^ Qf a web y Tfae web 

sive In particular, both the S-HTTP and SSL security fof e , the ^ fof [{s idemifief and 

mechanisms involve a handshake-based key distribution ^ informalion al lhe beginning of a browsing sess ion 
which utilizes complex public key cryptography techniques. and then ^ (he and secret information t0 ate 

A user desiring to conduct a series of low-cost secure keys for eac h server the client interacts with during 

transactions with a vendor over the Internet is therefore 55 ^ brQWsi sessiQD After a iven shared k [s 
required to utilize complex and costly arrangements, even eslablished> the web proxy automatically regenerates the 
though the transactions are carried out within an ongoing shafed fc eacfa %imc ^ cliem iniliates a transaction wilh 
client-server relationship. lfae In lhis manncrf the usc of the 

A need therefore exists for improved security techniques shared key can be made subs tantiaUy transparent to the 

for electronic transactions, which take advantage of an <® clienl> and the slQrage and computation overheads associ- 
ongoing. client-server relationship to provide transaction ated ^ lhe use of the shared key arc minimized, 
security without the complexity and cost associated with 

conventional public key techniques. BRIEF DESCRIPTION OF THE DRAWINGS 

SUMMARY OF THE INVENTION 65 F1G 1 shows ^ exemplary system in which the transac- 
The invention provides security protocols that are par- tion security techniques of the present invention may be 
ticularly well-suited for providing security in a series of implemented. 
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FIG. 2 illustrates an exemplary simple key establishment 
protocol (SKEP) in accordance with the invention. 

FIG. 3 shows an extension to the key establishment 
protocol of FIG. 2 which allows a client to obtain a receipt 
which is provable to a third party. 

FIG. 4 illustrates an exemplary simple data delivery 
protocol (SDDP) which provides privacy of data, source 
authentication and data integrity. 

FIG. 5 illustrates an extended data delivery protocol 
(EDDP) in which a client demonstrates possession of a 
shared key before data is delivered. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The present invention will be illustrated below in con- 
junction with a number of exemplary security protocols. It 
should be understood, however, that the invention is more 
generally applicable to any type of electronic transaction or 
other communication in which it is desirable to provide 
security without the complexity associated with conven- 
tional public key cryptography. Although particularly well- 
suited for use with communications over the Internet or 
other computer networks, the invention can also be applied 
to numerous other secure transaction applications, including 
applications based on smart cards. The term "web proxy" as 
used herein is intended to include, for example, any program 
or other device which serves as an intermediary between a 
browser or other user program and a web server, and through 
which information configured in accordance with the Hyper- 
text Transfer Protocol (HTTP) is routed. A web proxy in 
accordance with the invention may, for example, run on a 
client processor, on a server within an "intranet" associated 
with the client or on any other suitable processor arranged to 
communicate with the client. The term "random nonce" is 
intended to include a non-repeating value which appears 
substantially random to any entity other than the entity 
which generated it. 

FIG. 1 shows an exemplary system 10 in which electronic 
transaction security may be implemented in accordance with 
the invention. The system 10 includes a number of clients 
12-i, 2, ... N connected to a network 14. A number of 
servers 16-j, j=l, 2, . . . M, are also connected to the network 
14. Each of the clients 12-i includes a processor 20-i coupled 
to a memory 22-i, and each of the servers 16-j includes a 
processor 24-j coupled to a memory 26-j. One or more of the 
clients 12-i and servers 16-j may be implemented as a 
personal, micro or mainframe computer, a computer 
workstation, or other digital data processor as well as 
various portions or combinations thereof. The processors 
20-i and 24-j may represent a microprocessor, a central 
processing unit, an application-specific integrated circuit 
(ASIC) or other suitable processing circuitry. The memories 
22-i and 26-j may be electronic, magnetic or optical memo- 
ries. The network 14 may be a local area network, a 
metropolitan area network, a wide area network, a global 
data communications network such as the Internet, a private 
"intranet" network or any other suitable data communication 
medium. The clients 12-i and servers 12-j execute software 
programs which provide security for electronic transactions 
in a manner to be described in conjunction with FIGS. 2 
through 5 below. 

The transaction security techniques of the present inven- 
tion are based on "persistent" shared keys, which are estab- 
lished between a client and a server and persist for the 
duration of a client-server relationship. Il will be shown 
below that these techniques are well suited for securing 
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low-cost transactions which repeatedly execute between a 
client and a server. Examples of applications which involve 
these low-cost transactions may include delivery of person- 
alized information by a vendor via a web page, secure 

5 subscriptions to various types of information (e.g., person- 
alized stock quotes which a vendor sends to a client on a 
daily or hourly basis), payment transactions involving banks 
or other financial institutions, and delivery of client receipts 
which are provable to third parties, jn accordance with t he 

30 invention a client-side web proxv_ma\LbeLUSed to .compute,. 
secure shared keys on behalf of a g iven client. JT he cpmpu^ 
tation ma y be based oji a server identifi er, a client identifier, 
and a single secret p iece^pJLjniQrmatio^ by the_ 

client. The shared keys are allowed to persist between! 

15 Drowsing sessions of the client. However, the client need not 1 
store any shared keys, or any other security information. I 
Instead, the persistent shared key may be recomputed by the I 
web proxy when required, and in a manner which is trans- ' 
parent to the client. A server accepts and stores the shared 

20 key generated by a client on their first interaction. This 
shared key storage can be easily integrated into an otherwise 
conventional client record which is typically stored at the 
server. The modular structure of the security techniques of 
the present invention allows the complexity and cost of 

25 securing a transaction to be adjusted in accordance with the 
importance and monetary value of the transaction. 

The above-described properties indicate that a client need 
not rely on data stored in its memory, and the security 
techniques of the invention are therefore suitable for mobile 

30 computing applications. The above-noted web proxy that 
operates on behalf of the client is not required to maintain 
any information about the client. Therefore, the client can 
use various instances of the web proxy interchangeably. For 
example, different copies of the same web proxy may be 

35 used on a personal computer and a laptop computer asso- 
ciated with a given client. The client can then transparently 
continue interacting with a given server when switching 
from the personal computer to the laptop computer. 
The invention may be implemented using a very simple 

40 client interface. In a first interaction with the web proxy, 
such as when starting to run a browser program, the client 
provides an identifier, such as an e-mail address, and an 
additional secret piece of information. The client can sub- 
sequently reconnect transparently to any server which has 

45 appropriate session information. The invention does not 
require a client to obtain and maintain its own public and 
private keys or certificates. The client information can be 
stored on a smart card or in a secure file and then submitted 
to the web proxy automatically on behalf of the client. The 

50 invention gains computational efficiency by minimizing the 
use of public key cryptography techniques. 

The client-side shared key generation aspects of the 
invention will now be described in greater detail. In an 
illustrative embodiment, il is up to the client to compute a 

55 different persistent shared key for each server with which the 
client interacts. The servers will also be referred to herein as 
vendors. The client submits to a given vendor a client 
identifier, such as an e-mail address, and a shared key, which 
are to be used by both parties during their subsequent 

60 interactions. The shared key is private and should be pro- 
tected during communication. Therefore, before sending the 
shared key to the vendor, the client uses a public key of the 
vendor to encrypt the shared key. Public key encryption is 
thus utilized only during the initial interaction with a vendor. 

65 After this first exchange, both the client and the vendor can 
use the shared key in their subsequent interactions to authen- 
ticate and encrypt data with low computational cost. 
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An important aspect of the invention is the manner in will be assumed for simplicity that s c comprises the con- 

which the client computes the persistent shared key. An catenation of two strings, such that s c =s c 1 || 

exemplary shared key may be computed as a function of function J is then defined as follows: 
three arguments: (1) a client identifier, such as an e-mail 

address; (2) a single piece of secret information provided by 5 

the client; and (3) a vendor identifier, such as the domain j(u/ c , id v , Jc^C^JIUj 2 ^^©"'*:)) 
name in the Universal Resource Locator (URL) of the 

vendor. In an illustrative embodiment of the invention, the Additional details regarding the Janus function J and its 

function computes a string having the following desirable ^T^T*? ^ «u * h u ^ 

... . t * ... T . n 30 P. Gibbons, Y. Matias and A. Mayer, "How to Make Per- 

properties, with respect to an adversary with polynomially , ' , „. . £ . A 

u j j * *• i /i\ • Z u sonalized Web Browsmg Simple, Secure and Anonymous, 

bounded computational power: (1) secrecy, in that the result- Pf0ceedi of Financ & ia , Cryptography '97, Springer- 

mg string is indistinguishable from a random string; (2) Vefl 19Q? which ^ inco aled by reference hereirL 

consistency, in that the computed shared key for a given A yendor slQres a given diem identifier and the mm _ 

vendor is consistent; (3) efficiency, in that the computation a5 sponding shared keV) and p^j^y additional data such as 

of the shared key is efficient; (4) modular security, in that client preferences, on the first interaction with the client. The 

knowing the shared keys of the client for some vendors vendor can then retrieve the corresponding key upon being 

cannot help an adversary in guessing the shared key for presented with the stored client identifier on a subsequent 

another vendor; and (5) impersonation resistance, in that interaction. A number of illustrative protocols for cstablish- 

given a vendor and a client, an adversary cannot do better 20 ing persistent shared keys, and for subsequent interaction 

than guessing the client identifier and the secret piece of between a client and a server, will be described in conjunc- 

information. Alternative embodiments of the invention may tion with FIGS. 2 through 5. In the following description, 

utilize other functions which provide only a subset of these E^x) will denote the encryption of a plaintext message x 

properties, or other desirable properties not listed above. with a public key K, and S^x) will denote the signature of 

A . , » 1 1 1 j 1 * .• u 25 x with a private key k. It will be assumed for purposes of 

As noted previously, the shared key computation may be ... . 4 . r . , . : . , . . . -r j ur 

- , r 1 i_ i_ ir i .i_ i- * i_ i_ illustration that a given client can obtain a certified public 

performed transparently on behalf of the client by a web , c , j ^ / \ n j . . • 

r ™ f . iL ,. t key for each vendor. EnCjUx) will denote a symmetric 

proxy. The web proxy may be running on the client J c tU . . . * u a i v 

v J . - . j-rr u encryption of the plaintext message x with a shared key K, 

processor, or alternatively on a different computer with , n J T * .u *• *.u .l 

t. • l *u 1 ■ . u * j l aQ d MAC*- will denote a message authentication with the 

which the client has trusted communication, such as a server . , JC . A . r» . u ji 

. , r.. i- . tt iL cl . • . f 30 shared key K. If two parties A and B have a shared key 

within an mtra-net of the client. Upon the first interaction of „ /T , v \ t-w*^ / \ 1- / mi wa ^ rr- / w\ • 

tU ,. t ... . . ^ , , . . K=(K,, K 2 ), EMAC Jt (x)=Enc^ 1 (x) MAG^flinCx^x))) is a 

the client with the web proxy, such as when starting a u ■ • . Y * a a t> .u . 

u *u * • ~* .j ,1 • , * • 1 basic secure communication step between A and B that 

browser program, the client provides the above-noted single ... - . iL . t , . . . , 

. • r - r «* u - u .u .u cT enables delivery of an encrypted authenticated plaintext 

secret piece of information, which the proxy uses thereafter J Jtr r 

to compute a shared key for each vendor the client interacts „ me ™j!F^»*ii . . *u c % 1 t .,■ . 

• . « j - ,1 . * . . Tt .„ . Jf 35 FIG. 2 illustrates the operation of a simple key establish- 

with during that browsing session. It will be assumed for . x^™™ . , ■ ^™ 

% .„ t . l ■ . .u . n v me nt protocol (SKEP) m accordance with the invention. The 

purposes of illustration herein that the term client can ot^tT .1 v * . . . ^ . „ 

f T . .u u *u * * r SKEP protocol may be used when a client C requests to 

include a user, the browser program or other user interface, . 4 v ... j r iL ^ . 

... l* 1 ■ . .1. u J register or subscribe at a vendor V for the first time. The 

user-assisting programs such as plug-ins to the browser, and . „ „ . .. , n c . c ... 

tl _ . * r i- * *• . diagram in FIG. 2 indicates the now of information between 

the web proxy. A reference to a client computing or execut- , j j t 

r . iL ... . . 1 l u L 40 client C and vendor V. The client C first computes a 

ing an operation in the illustrative examples should be . . , . /T _ T . x T _ . r T/ ., 

* j . * . ... 4l . . t t , r t persistent shared key KKK^Ko) as the Janus function J(id^, 

understood to include without limitation the computation or • j \ ■ .u ■ ■ f a ^ a I 

. Ut . , Af . r y t . s 0 id v ) in the manner previously described. The component 

execution by the web proxy. A reference to a client supply- S X \ A . v -n u -if j .u 

. u u u j . . . . . , ... t .. f. K t of shared key K will be used for encryption, and the 

ing input should be understood to include without limitation 1 . , e t , . . Jr ™ . ^ 

tU & r i-.u-.*u u .u • .• component K, will be used for authentication. The client C 

the user supplying the >npu. through the user-assistmg 45 P ^ form E 1o vcndor v> 

IS 'a^r™ 5515 8 program sup mg mp OD where 55 ' he p 6 ^ 01 sh ^ d K encr yp ,ed 

using the public key PK V of the vendor V, and R c is a 

An illustrative embodiment of the invention uses the random nonce. The vendor V then decrypts £ PK JK) to 

Janus function J for the client-side computation of shared obtain the shared key K. The vendor V then replies as shown 

keys. The Janus function J is defined in the context of 50 in FIG. 2 with EMACj^R c ||R v ), where R v is a random 

personalized, anonymous interaction in U.S. patent applica- nonce of the vendor. The client C decrypts this message, 

tion Ser. No. 08/787,557, filed Jan. 22, 1997 and entitled verifies the MAC and its own random nonce R c , and sends 

"System and Method for Providing Anonymous Personal- the message EMAC^ (Rv||id<r||/<?) 10 vendor V, where I c 

ized Browsing in a Network," which is incorporated by contains possible subscription data, such as a credit card 

reference herein. The function J is based on pseudo-random 55 number, start date, expiration date, and so on. The vendor V 

functions and collision-resistant hash functions, as described decrypts the message, verifies the MAC, compares R v to 

in O. Goldreich, S. Goldwasser and S. Micali, "How to what it sent earlier, and stores the client identifier id c and the 

Construct Random Functions," Journal of the ACM, Vol. 33, data \ c in a record established for client C. The client C and 

No. 4, pp. 210-217, 1986 and A. Menezes, P. Van Oorschot vendor V have thus established a persistent shared key K 

and S. Vanstone, "Handbook of Applied Cryptography, CRC 60 which may be used for multiple low-cost transactions with- 

Press, 1997, respectively, both of which are incorporated by out further use of public key cryptography techniques, 

reference herein. Let h be a collision-resistant hash function It can be shown that the SKEP protocol illustrated in FIG. 

and let f k be a pseudo-random function chosen from a set F, 2 provides a number of desirable features to the client, 

of pseudo-random functions using k as a seed. Let ||denote including: (1) key authentication, that is, assurance that no 

concatenation and © denote exclusive or. Let id c denote the 65 party other than the intended party can gain access to the 

client identifier and id v denote the vendor identifier. Finally, shared key; (2) entity authentication, that is, assurance of the 

let s c denote the piece of secret information of the client. It identity of the intended other party and knowledge that the 
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intended other party actually participated in the transaction; C checks that the random nonce K v is unchanged, and then 
and (3) key confirmation, that is, assurance that the intended replies with EMAC A <Rd|RyR(D c v )) as shown, where R c 
other party is in possession of the shared key. The SKEP and R(D C V ) are a random nonce and information request, 
protocol also provides key confirmation and entity authen- respectively, of the client. The vendor V decrypts using the 
ticat ion to the vendor, in that the vendor can be assured that 5 shared key, verifies the MAC and checks that R v is 
it interacts with a party which actually possesses the per- unchanged. The vendor V then replies with a message 
sistent shared key K and valid identifying information such EMAC^Rjpc. K ). The client C decrypts this message 
as a valid credit card number. Although this vendor assur- using the shared key K to obtain the requested information 
ance is weaker than the assurance provided to the client by D c y, again checks that the random nonce R c remains 
the certified public key of the vendor, it is consistent with the 10 unchanged from the value submitted previously by vendor 
vendor assurances currently accepted by many popular web V, and verifies the MAC. In addition to the above-described 
sites. properties of the SDDP protocol, the EDDP protocol pro- 
FIG. 3 shows an additional message which may be sent vides mutual authentication before any data is exchanged 
from the vendor V to the client C in order to provide a and therefore provides better protection against the above- 
non-repudiation property in the SKEP protocol. The non- 15 noted denial of service attacks. In addition, as previously 
repudiation property allows the client to obtain a receipt, noted, the information request itself is encrypted and there- 
provable to a third party, of its transaction with the vendor, fore third parties are unable to determine what type of 
such that the vendor cannot later deny having conducted the information the client has requested. Furthermore, the 
transaction with the client. As shown in FIG. 3, the vendor shared key is better protected, since only the corresponding 
V, after receiving the last message of the basic SKEP 20 client can prompt the vendor to use it for encryption and 
protocol of FIG. 2, sends a message which includes a vendor authentication. 

signature on the client identifier id c and the transaction data The above-described protocols are suitable for use in a 

I c , encrypted using the K a portion of the shared key K. The wide variety of applications. For example, the protocols may 

message is given by Enc Jcl (S >s:/fV (id c )|I c )), where is a be used in an application in which the vendor V may 

signature generated using the secret key of the vendor V. The 25 operates an Internet web site which provides free personal - 

client C can decrypt the message using the K x portion of the ized stock quotes. In this case, the requested information 

shared key K, and a third party can verify that the signature D c v may be a personalized web page containing a set of 

is indeed that of the vendor V. stock quotes for a given client C, the client identifier id c is 

FIG. 4 illustrates an exemplary simple data delivery its email address, and the transaction data l c is empty. The 
protocol (SDDP) in accordance with the invention. The 30 SKEP protocol is used to establish a shared key, and the 
SDDP protocol is used in this example when the client C SDDP protocol may be used to supply the requested infor- 
requests information D c v from the vendor V. As shown in mation. In an application is which a client C purchases a 
FIG. 4, the client C sends a request R(D C v ) to the vendor V, subscription to personalized stock quotes from the vendor V, 
along with the client identifier id c and the random nonce R c . the client identifier id c is again its email address, and the 
The vendor V attempts to locate a previously-established 35 transaction data I c includes the client credit card data and the 
shared key K associated with the client identifier id c . If the duration of the subscription. Non-repudiation key exchange 
shared key K is found, and the corresponding stored infor- in accordance with FIGS. 2 and 3 is appropriate in this case, 
mation I c indicates that the client account is valid, the given that it allows a client to use the vendor signature as a 
vendor V responds with a message EMACk(R c ||D c v ). The receipt. The EDDP protocol is preferable for delivering the 
client decrypts this message using the shared key K to obtain 40 data in this case, as the service is restricted to paying clients 
the requested information D c v , checks that the random and thus the vendor would like to provide adequate service 
nonce R c is unchanged from the value submitted previously for these clients in the presence of a denial of service attack, 
by vendor V, and verifies the MAC. It can be shown that the The security protocols of the invention exhibit minimal 
illustrative SDDP protocol of FIG. 4 provides privacy of computation and memory costs. In the illustrative protocols, 
data, source authentication of the vendor V to client C, and 45 the vendor signs no more than a single message per client, 
data integrity of the requested information D c v . However, All subsequent communication is performed via encryption/ 
it should be noted that the SDDP protocol provides no real MAC. The client has to public key encrypt a single message 
source authentication to the vendor. As a result, the vendor per vendor upon first interaction, and uses only MAC 
could be prompted via impersonation attacks to send data, processes in subsequent interactions with a given vendor. In 
even though the data might not be readable by the requesting 50 addition, the client computes one Janus function per brows- 
entity, thereby creating a potential problem in terms of ing session and vendor. The client therefore does not require 
denial of service. An alternative protocol to be described in any long-term memory resources to implement the proto- 
conjunclion with FIG. 5 below alleviates this potential cols. The vendor stores a persistent shared key K for each of 
problem with the SDDP protocol of FIG. 4. its clients. Given that the vendor already stores some infor- 

FIG. 5 shows an exemplary extended data delivery pro- 55 mation about each of its clients, the additional storage 

tocol (EDDP) in accordance with the invention. The EDDP attributable to the shared key is not place any significant 

protocol is similar to the SDDP protocol previously extra burden on the vendor. 

described, but requires the client C to demonstrate posses- Alternative embodiments of the invention may avoid 

sion of the appropriate shared key to the vendor V before the exposing a persistent shared key by replacing it with a fresh 

vendor will deliver the requested information, and also hides 60 session key for every transaction. Such a session key could 

from third parties the type of information the client has be computed locally by both the client and the vendor, and 

requested. The client C sends the client identifier id c to the may be based on the persistent shared key and a counter, 

vendor V. The vendor V determines if the identifier id c Additional details regarding session key generation of this 

corresponds to a legitimate client, and examines the stored type may be found in, for example, A. Aziz and M. 

information I c to ensure that the client account is valid. If 65 Patterson, "Design and Implementation of SKIP (Simple 

these checks are passed, the vendor V replies with a message Key Management for Internet Protocols)," Proceedings of 

R v , where R v is a random nonce of the vendor V. The client the I NET '95 Conference, 1995, which is incorporated by 
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reference herein. Other embodiments of the invention may 
make use of the receipt techniques described in R. Rivest 
and A. Shamir, "Pay Word and MicroMind Two Simple 
Micropayment Schemes," 4** Cambridge Workshop on 
Security Protocols, 1996, which is incorporated by reference 5 
herein, to resolve situations in which, for example, a client 
complains of paying the vendor but never receiving the 
requested information and a third party is unable to deter- 
mine if the vendor is indeed at fault. Additional details 
regarding incorporation of security protocols such as those 10 
described herein into a protocol such as HTTP can be found 
in E. Gabber and A. Silberschatz, "Agora: A Minimal 
Distributed Protocol for Electronic Commerce," Second 
USENIX Workshop on Electronic Commerce, 1996, which 
is incorporated by reference herein. 

The above-described embodiments of the invention are 
intended to be illustrative only. Numerous alternative 
embodiments within the scope of the following claims will 
be apparent to those skilled in the art. 

What is claimed is: 

1. A method of secure communication between a client 
and a server, comprising: 

encrypting a shared key, generated in association with the 
client, using a public key associated with the server; 

sending the encrypted shared key to the server; 

receiving a response from the server incorporating infor- 
mation encrypted using the shared key; and 

verifying acceptance of the shared key by the server, using 
the information in the response; 

wherein said accepted shared key is recomputed in asso- 
ciation with the client for use in an on-going client- 
server relationship which comprises one or more sub- 
sequent transactions between the client and the server, 
such that a separate key exchange for each transaction 35 
need not be performed and the accepted shared key 
need not be stored in association with the client 
between said transactions, and such that the use of said 
accepted shared key persists during the course of the 
on-going client-server relationship; 40 

further wherein the accepted shared key persists for a time 
period substantially larger than a related transaction 
time period associated with a secure socket layer (SSL) 
protocol thereby allowing the accepted shared key to 
persist for at least two transactions separated by a time 45 
period substantially larger than the SSL related trans- 
action time period, and wherein the client, during 
subsequent transactions, is able to use a communication 
device that is different than a communication device 
used during the key exchange. 

2. The method of claim 1 wherein the server stores the 
accepted shared key and an identifier of the client on an 
initial interaction with the client, and then retrieves the 
shared key upon being presented with the stored client 
identifier in a subsequent transaction. 

3. The method of claim 1 further including the step of 
sending additional client information from the client to the 
server if the information received in the response is verified 
as associated with the server. 

4. The method of claim 1 wherein an additional message 
is sent from the server to the client in order to provide a 
non-repudiation property for a transaction based on the 
accepted shared key, wherein the additional message 
includes a vendor signature on client information. 

5. The method of claim 1 further including the steps of: 
sending a request to the server along with a client iden- 
tifier; 



receiving a response to the request from the server, 
wherein the response is encrypted using the accepted 
shared key; and 
decrypting the response using the accepted shared key, to 
thereby authenticate the response and obtain the 
requested information. 

6. The method of claim 5 further including the step of 
requiring the client to demonstrate possession of the 
accepted shared key before providing the requested infor- 
mation. 

7. The method of claim 1 further including the step of 
generating the shared key at the client as a function of an 
identifier of the client, an identifier of the server, and secret 
information associated with the client. 

8. The method of claim 7 wherein the function is a Janus 
function. 

9. The method of claim 1 further including the step of 
generating the shared key in a web proxy associated with the 
client. 

10. The method of claim 9 wherein all long-term memory 
20 utilized by the web proxy is unsecure. 

11. The method of claim 9 wherein the client utilizes a 
plurality of web proxies during the course of the on-going 
client-server relationship. 

12. The method of claim 9 wherein the accepted shared 
25 key is regenerated by the web proxy when required for a 

subsequent transaction between the client and the server, in 
a manner which is substantially transparent to the client. 

13. The method of claim 9 wherein in an initial interaction 
with the web proxy the client provides a client identifier and 
additional secret information used by the web proxy to 
generate the shared key. 

14. The method of claim 13 wherein the web proxy uses 
the client identifier and secret information provided in the 
initial interaction to compute a shared key for each of a 
plurality of servers with which the client interacts during a 
browsing session. 

15. An apparatus for use in providing a secure commu- 
nication between a client and a server, comprising: 

at least one processor associated with the client and 
operative: (i) to encrypt a shared key, generated in 
association with the client, using a public key associ- 
ated with the server, (ii) to send the encrypted shared 
key to the server, (iii) to receive a response from the 
server incorporating information encrypted using the 
shared key, and (iv) to verify acceptance of the shared 
key by the server using the information in the response, 
wherein said accepted shared key is recomputed for use 
in an on-going client-server relationship which com- 
prises one or more subsequent transactions between the 
client and the server, such that a separate key exchange 
for each transaction need not be performed and the 
accepted shared key need not be stored in association 
with the client between said transactions, and such that 
the use of said accepted shared key persists during the 
course of the on-going client-server relationship, fur- 
ther wherein the accepted shared key persists for a time 
period substantially larger than a related transaction 
time period associated with a secure socket layer (SSL) 
protocol thereby allowing the accepted shared key to 
persist for al least two transactions separated by a time 
period substantially larger than the SSL related trans- 
action time period, and wherein the client, during 
subsequent transactions, is able to use a communication 
device that is different than a communication device 
used during the key exchange; and 
a memory coupled to the processor for at least temporarily 
storing at least a portion of the information in the 
response. 
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16. The apparatus of claim 15 wherein the server stores 
the accepted shared key and an identifier of the client on an 
initial interaction with the client, and then retrieves the 
shared key upon being presented with the stored client 
identifier in a subsequent transaction. 

17. The apparatus of claim 15 wherein the processor 
generates the shared key as a function of an identifier of the 
client, an identifier of the server, and secret information 
associated with the client. 

18. The apparatus of claim 17 wherein the function is a 
Janus function. 

19. The apparatus of claim 15 wherein the processor is 
further operative to generate the shared key using a web 
proxy associated with the client. 

20. The apparatus of claim 19 wherein all long-term 
memory utilized by the web proxy is unsecure. 

21. The apparatus of claim 19 wherein the client utilizes 
a plurality of web proxies during the course of an on-going 
client-server relationship. 

22. The apparatus of claim 19 wherein the accepted 
shared key is regenerated by the web proxy when required 
for a subsequent transaction between the client and the 
server, in a manner which is substantially transparent to the 
client. 

23. The apparatus of claim 19 wherein in an initial 
interaction with the web proxy the client provides a client 
identifier and additional secret information used by the web 
proxy to generate the shared key. 

24. The apparatus of claim 23 wherein the web proxy uses 
the client identifier and secret information provided in the 
initial interaction to compute a shared key for each of a 
plurality of servers with which the client interacts during a 
browsing session. 

25. A method of secure communication between a client 
and a server, comprising: 

receiving in the server an encrypted shared key, wherein 
the shared key is generated in association with the 
client and encrypted using a public key associated with 
the server; 

generating a response incorporating information 
encrypted using the shared key; and 

transmitting the response to the client, wherein the client 
uses the information in the response to verify accep- 
tance of the shared key by the server; and 

wherein the accepted shared key is recomputed for use in 
an on-going client-server relationship which comprises 
one or more subsequent transactions between the client 
and the server, such that a separate key exchange for 
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each transaction need not be performed and the 
accepted shared key need not be stored in association 
with the client between said transactions, and such that 
the use of said accepted shared key persists during the 
course of the on-going client-server relationship; 

further wherein the accepted shared key persists for a time 
period substantially larger than a related transaction 
time period associated with a secure socket layer (SSL) 
protocol thereby allowing the accepted shared key to 
persist for at leasl two transactions separated by a time 
period substantially larger than the SSL related trans- 
action time period, and wherein the client, during 
subsequent transactions, is able to use a communication 
device that is different than a communication device 
used during the key exchange. 

26. An apparatus for use in providing secure communi- 
cation between a client and a server, comprising: 

a processor associated with the server and operative: (i) to 
receive an encrypted shared key, wherein the shared 
key is generated in association with the client and 
encrypted using a public key associated with the server, 
and (ii) to generate and transmit to the client a response 
incorporating information encrypted using the shared 
key, wherein the client can verify acceptance of the 
shared key by the server using the information in the 
response, and the accepted shared key is recomputed 
for use in an on -going client-server relationship which 
comprises one or more subsequent transactions 
between the client and the server, such that a separate 
key exchange for each transaction need not be per- 
formed and the accepted shared key need not be stored 
in association with the client between said transactions, 
and such that the use of said accepted shared key 
persists during the course of the on-going client-server 
relationship, further wherein the accepted shared key 
persists for a time period substantially larger than a 
related transaction time period associated with a secure 
socket layer (SSL) protocol thereby allowing the 
accepted shared key to persist for at least two transac- 
tions separated by a time period substantially larger 
than the SSL related transaction time period, and 
wherein the client, during subsequent transactions, is 
able to use a communication device that is different 
than a communication device used during the key 
exchange; and 

a memory coupled to the processor for storing the shared 
key. 



03/08/2004, EAST Version: 1.4.1 



